Traditional approaches to troubleshooting interface oversubscription currently utilized by clients and technical support providers involve connecting an external packet sniffer to analyze the ingress traffic on any device that uses Ethernet controllers showing overrun errors. Such an approach creates a number of challenges.
One problem with traditional approaches is that they are inefficient. It takes time to connect proper hardware after experiencing overrun errors on a particular interface once and then waiting to determine if the problem repeats itself. Depending on the frequency of problem occurrence, packet captures may be collected for an extended period of time, which in some cases may not even be operational possible. As it may be impossible to identify the timestamps in a given microburst, large amounts of effort are required to analyze any corresponding captures.
Furthermore, the ability to capture a microburst may depend on the capabilities of packet sniffer hardware. Since many network devices are based on similar general-purpose network interface cards, similar limitation with respect to handling interface oversubscription apply as well.
Even if the capture is collected successfully at the ingress of a particular network device, a corresponding capture at all of the egress points would still be required to determine what specific traffic was dropped. It becomes even more challenging with the implementation of firewalls and other security devices as some traffic may be dropped for security reasons and not due to oversubscription. In other words, there is no straightforward way to identify specific traffic that was dropped due to exceeding available FIFO queue space at the ingress interface.